Day 3｜營運 & 成效驗證：Dashboard、A/B、ROI、Roadmap

目標：把系統從「能跑」升級成「能長跑」。今天交付可直接上台的監控儀表板、A/B 測試腳本模板、成本 vs 成效腦補表、上線檢核清單。

0) TL;DR

• 資料源：ESP32-CAM 取像→Flask 收檔→（Rekognition/向量比對）→看板/APP，事件同時寫入 DB（例：SQLite）做日/週報表。
• 輸出端：Chromecast with Google TV 以 Kiosk 模式播放對應廣告頁；同時回寫資料供 Dashboard。
• 雲端配置：Flask +（GCP VM / Cloud Run），管理環境變數如 LINE_CHANNEL_ACCESS_TOKEN、DEFAULT_PERIOD_SEC、ALWAYS_NOTIFY 等，便於排程與節流。

1) 監控儀表板

(A) 24h 系統健康（抓取/比對/推播）

時段   | 上傳成功 | 比對OK | 推播次數 | 失敗重試
00-03 |    720   |  708   |    8    |    2
03-06 |    720   |  716   |    6    |    1
06-09 |    720   |  703   |   12    |    5
09-12 |    720   |  711   |   18    |    3
12-15 |    720   |  705   |   21    |    6
15-18 |    720   |  709   |   17    |    2
18-21 |    720   |  713   |   24    |    3
21-24 |    720   |  710   |    9    |    2

(B) 推播漏斗（一天）

偵測到人臉/向量候選：  312
相似度過門檻(高/中)：  176
品類/偏好匹配通過   ：  152
冷卻/頻控通過       ：  134
→ 實際推播         ：  134 （漏斗通過率 42.9%）

(C) 高機率觸發時段（迷你圖）

時段   | 觸發數 | 迷你圖
10-12 |   32  | ▃▃▃▃
12-14 |   48  | ██████
18-21 |   55  | ███████
21-23 |   12  | ▂▂

儀表板的原始事件來自：ESP32-CAM 上傳影像、Flask 後端持續收檔與比對、再把決策與素材 URL 回寫資料庫，支撐日/週報視圖。

2) 指標怎麼蒐集？（事件欄位設計）

事件表（events）範例欄位

ts（UTC ISO） | cam_id | img_path | decision(match/unknown) | score(相似度/距離)
asset_url(素材頁) | latency_ms | push_channel(signage/app) | error_code

資料流回寫

[ESP32-CAM] → [Flask /upload] → [比對引擎(雲端API)]
           ↘  [SQLite/日誌寫入]  ↘ [asset_url 決策] → [Kiosk/APP]

3) A/B 測試：文案 × 價格帶 × 版位

A/B 設計表

冷卻與頻控

同一人(向量近似) 15 分鐘內不重推
同一品項 30 分鐘內不重推
尖峰時段提高門檻（只推高信心或高分商品）

4) 成本 vs 成效（ROI 腦補表）

假設：每店一台、每 5 秒 1 張、每日 12 小時、30 天 ≈ 259,200 張/月。

實際金額依官網與合約為準。

重點：先用雲端 API 快速起飛；待成效穩定，再評估「混合：高隱私點位改走地端；其餘走雲端」，文件亦描述過地端/雲端雙線策略。

5) 雲端部署與環境變數（可直接抄）

Cloud Run／VM 常用套件（節錄）

Flask==3.0.3, gunicorn==21.2.0
requests==2.32.3, beautifulsoup4==4.12.3, lxml>=5.3
line-bot-sdk>=3.11,<4
google-cloud-firestore==2.16.0, grpcio>=1.74

重要環境變數（文件列示）

LINE_CHANNEL_ACCESS_TOKEN, LINE_CHANNEL_SECRET
DEFAULT_PERIOD_SEC     # 預設監看間隔(秒)
ALWAYS_NOTIFY          # 0=僅變化才通知, 1=每次都通知
MAX_PER_TICK           # 同步執行任務數上限
TICK_SOFT_DEADLINE_SEC # 一輪排程截止秒

6) ASCII 版「本週週報」

(A) 通知成效（週）

日      曝光  互動(%)  推播  轉換(%)  熱門品類
Mon    4120   8.5     305   14.9     甜點/健康飲品
Tue    3980   8.2     291   15.4     甜點/早餐穀物
Wed    4350   8.8     327   15.1     健康飲品/咖啡
Thu    4210   8.1     310   14.7     甜點/飲品
Fri    5020   9.1     366   15.8     甜點/咖啡
Sat    5330   9.4     392   16.1     甜點/親子
Sun    4880   8.9     355   15.6     飲品/甜點

(B) 觸發熱區（門市樓層 × 時段）

樓層\時段 | 10-12 | 12-14 | 18-21
B1(餐飲) |  ▃▃   | ████  | █████
1F(精品) |   ▂    |  ▃▃   |  ███
2F(生活) |  ▃▃   |  ▃▃▃  |  ███

7) 風險 & 合規（現場 SOP）

• 最小化保存：盡量僅存向量或必要摘要，影像可即拋棄；尊重場域規範。
• 門檻分級：中段信心值（文件的「向量比對」章節主張）採保守策略或人工複核。
• 現場揭露：清楚標示用途、保存區間、聯絡窗口。
• 頻控：冷卻時間＋尖峰提升門檻，避免洗頻與廣告疲勞。

8) Roadmap

商機驗證 → MVP（ESP32-CAM→雲端比對→Kiosk） → A/B 測試
→ 週報/Dashboard → 混合架構（地端 + 雲端） → 多平台支援（tixCraft/KKTIX）

9) 可貼的程式小工具（把 CSV 變簡易圖）

匯出 events.csv 後，用下列腳本產生每小時推播次數的 ASCII 長條圖（可貼在週報）。

# ascii_chart.py
import pandas as pd
df = pd.read_csv("events.csv")                  # 欄位含 ts, decision
df["ts"] = pd.to_datetime(df["ts"])
s = (df[df["decision"]=="match"]
     .set_index("ts")
     .resample("1H")
     .size())
for ts, v in s.items():
    bar = "█" * int(v/2) if v>0 else ""
    print(ts.strftime("%m-%d %H:00"), f"{v:3d}", "|", bar)

10) 上線檢核（Checklist）

• [ ] Cloud Run/VM 可穩定收檔，事件都有落 DB（SQLite/雲端）。
• [ ] Kiosk 正常播放素材 URL；尖峰時段延遲可接受。
• [ ] A/B 測試就緒：文案/價格帶/版位 各 2 版；冷卻與頻控生效。
• [ ] 週報自動輸出（曝光、互動、推播、轉換、熱門時段/品類）。
• [ ] 成本控管：依實際人流調整頻率；雲端 API 帳單監控。
• [ ] 隱私與揭露：現場張貼、向量化保存策略、聯絡窗口到位。

小結：把「偵測→比對→推播→回寫」的閉環跑順後，報表就會說話。接下來，只要沿著 A/B 與成本監控持續優化，你們的「你的專屬折扣」就能在更多據點穩定拓展。
參考：ESP32-CAM 能以 HTTP 上傳影像、Flask 後端與 Rekognition/向量比對、Kiosk 顯示與 SQLite 回寫。